System for improving data security

ABSTRACT

A system allows a user to store his personally identifiable information (PII) on a personal device. When a third party wants to access the user&#39;s PII (e.g., to update the PII or to retrieve the PII), a notification will be presented to the user on the personal device seeking consent to the access. The notification may inform the user as to what information is being requested and which entity is requesting the access. The requested access will be denied unless the user consents to the access. In this manner, the user is given control over the dissemination of his PII. Additionally, the system alters or adjusts the PII that is stored in third-party servers so that even if these servers are breached, the user&#39;s actual PII is not exposed.

TECHNICAL FIELD

This disclosure relates generally to a system that protects againstunwanted access to stored information (e.g., a user's personallyidentifiable information).

BACKGROUND

Users provide their information (e.g., name, address, telephone number,email address, social security number, etc.) in a variety of contexts(e.g., mortgage applications, credit card applications, financialaccount applications, air travel ticket orders, medical office visits,etc.). If this information were exposed to or taken by a malicious user,then the malicious user would be able to use this information toimpersonate the users to conduct undesired or unwanted transactions.

SUMMARY OF THE DISCLOSURE

Users provide information (e.g., name, address, telephone number, emailaddress, social security number, etc.) in a variety of contexts (e.g.,mortgage applications, credit card applications, financial accountapplications, air travel ticket orders, medical office visits, etc.). Ifthis information were exposed to or taken by a malicious user, then themalicious user would be able to use this information to impersonate theusers to conduct undesired or unwanted transactions.

In conventional systems, the users have very little control over thisinformation. The users provide their information to a provider to gainaccess to goods or services from the provider. The provider maintainsthe information (e.g., on a server). If that server were to be breachedby a malicious user, the information would be exposed to the malicioususer. Additionally, some providers even sell the information to otherproviders, often unbeknownst to the users. This sale and movement of theinformation further exposes the information to malicious users andlessens the control that the users have over such information.

This disclosure contemplates an unconventional system for securinginformation (e.g., a user's personally identifiable information (PII)).Generally, the system allows the user to store his PII on a personaldevice, such as a smartphone. When a third party wants to access theuser's PII (e.g., to update the PII or to retrieve the PII), anotification will be presented to the user on the personal deviceseeking consent to the access. The notification may inform the user asto what information is being requested and which entity is requestingthe access. The requested access will be denied unless the user consentsto the access. In this manner, the user is given control over thedissemination of his PII. Additionally, the system alters or adjusts thePII that is stored in third-party servers so that even if these serversare breached, the user's actual PII is not exposed.

According to an embodiment, a system includes a device of a user and atoken handler separate from the device. The device receives personallyidentifiable information the user and encrypts the personallyidentifiable information to produce first encrypted personallyidentifiable information. The token handler receives the first encryptedpersonally identifiable information from the device of the user,decrypts the first encrypted personally identifiable information toproduce the personally identifiable information, generates a tokenrepresenting the personally identifiable information, and receives thetoken indicating a request for the personally identifiable information.The device receives consent from the user to provide the personallyidentifiable information in response to the request for the personallyidentifiable information, in response to receiving the consent from theuser, encrypts the personally identifiable information to produce secondencrypted personally identifiable information, and communicates thesecond encrypted personally identifiable information to the tokenhandler.

When PII is to be stored or updated, the system first seeks consent fromthe user for the PII store or update. If the user grants consent, thenthe system stores the

PII in the user's personal device or updates the PII stored in theuser's personal device. The system then generates a token representingthe PII. The token can be presented at a later time to redeem or accessthe PII, subject to the user's consent. Even if the token were taken bya malicious user, it would not be possible for the malicious user todetermine the user's actual PII from the token. In this manner, thesecurity of the PII is improved over conventional systems.

According to an embodiment, a system includes a token handler and adevice of a user separate from the token handler. The token handlerreceives, from a data originator, a request to store a user's personallyidentifiable information, the request to store comprising the user'spersonally identifiable information encrypted using a public encryptionkey of the token handler and inserts into a first queue the request tostore. The device establishes a connection with the token handler. Thetoken handler updates a status of the request to store in a second queuein response to determining that the device has established theconnection. In response to the updated status of the request to store inthe second queue and after establishing the connection, the devicepresents a notification message to the user seeking consent to store theuser's personally identifiable information and in response to receivingthe consent from the user, the device encrypts, using a saltedpassphrase of the user, the user's personally identifiable informationencrypted using the public encryption key of the token handler toproduce the user's personally identifiable information encrypted usingthe public encryption key of the token handler and the salted passphraseand stores the user's personally identifiable information encryptedusing the public encryption key of the token handler and the saltedpassphrase in a local repository. The token handler, in response todetermining that the device has stored the user's personallyidentifiable information encrypted using the public encryption key ofthe token handler and the salted passphrase, generates a tokenrepresenting the personally identifiable information, and furtherupdates the status of the request to store in the second queue.

When a third party wants to redeem the user's PII, the third partypresents to the system the token, which indicates a request for the PIIrepresented by the token. The system seeks consent from the user forsending the PII to the third party. If the user grants consent, then thesystem prepares the PII for the third party. In some embodiments, thethird party can receive the PII directly from the system.

In certain embodiments, tokens are not directly accessible by thirdparties. Instead, when a third party wants to redeem the user's PII, thethird party presents to the system anonymized data, which indicates arequest for the PII used to form the anonymized data. The token handlerthen uses the anonymized data to select a suitable data access token.

In some embodiments, the objective of presenting anonymized data or adata access token is to obtain a service. During redemption, the PII isdispatched to a third party service to be used to make a request forthat service. For example, consider an organization wishing to grant aconsultant temporary access to a database when she joins thatorganization, and revoke that access when her employment concludes. Thedatabase is accessed by a database server and is protected by a usernameand a password. With the contemplated system, the organization can givethe consultant temporary credentials and later revoke them withoutrevealing or altering the true database credentials. Additionally,assume there is another server that can proxy the database server. Whenpresented with anonymized versions of the username and password in adatabase query submitted by the consultant, the proxy server can look upa token to redeem the anonymized credentials for the real databasecredential on the employee's behalf. Subsequently, the token handlerobtains the real database credentials and injects the real credentialsinto the database query. The proxy then submits the query to thedatabase server for processing. Thus, the consultant gained access tothe database but not access to the real database credentials. When theconsultant's employment concludes, the data access token associated withher anonymized username and password is removed from the token handler.If subsequent database queries are submitted with her credentials, theywill fail. In such a scenario, the PII is secrets belonging to anorganization. The data access tokens are entitlements.

In an embodiment, the credentials injected into the final database queryin the above example are encrypted with a public key of the databaseserver, securing them in transit between the proxy and the databaseserver.

In an embodiment, the token may not be associated with any data;instead, it is simply an entitlement. For example, it may represent anentitlement to activate a subscription or service, potentially a freetrial to a content streaming service. In this example, the anonymizeddata represents a code for access to the service. That access iscontrolled by the token, which may be updated, replaced, deleted, orconfigured to expire or throttle the user's access.

According to certain embodiments, a system includes a token handler anda device separate from the token handler. The token handler receives,from a data originator, a token representing personally identifiableinformation and in response to receiving the token from the dataoriginator, inserts into a first queue a request to redeem personallyidentifiable information of a user corresponding to the personallyidentifiable information. The device stores the personally identifiableinformation encrypted using a public encryption key of the token handlerand establishes a connection with the token handler. The token handlerupdates a status of the request to redeem in a second queue in responseto determining that the device has established the connection. Inresponse to the status of the request to redeem in the second queue andafter establishing the connection, the device presents a notificationmessage to the user seeking consent to redeem the personallyidentifiable information and in response to receiving the consent fromthe user, the device encrypts, using a public encryption key of the dataoriginator, the personally identifiable information encrypted using thepublic encryption key of the token handler to produce the personallyidentifiable information encrypted using the public encryption key ofthe token handler and the public encryption key of the data originatorand communicates the personally identifiable information encrypted usingthe public encryption key of the token handler and the public encryptionkey of the data originator to the token handler.

The system further protects PII by implementing an unconventional keymanagement scheme. In this scheme, the system uses a set of keys ratherthan an individual key for encrypting PII. Different portions of the PIIare encrypted using different keys from the set of keys. In this manner,even if a malicious user were to access a key, that key would not givethe malicious user the ability to decrypt all of the PII. Additionally,the system generates a new set of keys periodically (e.g., once amonth). The system also deletes sets of keys that are too old (e.g., sixmonths old). As a result, even if a malicious user were to access a key,the usefulness of that key would be time limited.

According to an embodiment, a token handler includes a memory and ahardware processor. The processor generates a set of public encryptionkeys of the token handler and communicates the set of public encryptionkeys of the token handler to a data originator. The processor alsoreceives, from the data originator, a request to store a user'spersonally identifiable information. The request to store includes afirst portion of the user's personally identifiable informationencrypted using a first public encryption key of the token handler fromthe set and a second portion of the user's personally identifiableinformation encrypted using a second public encryption key of the tokenhandler from the set. The processor further adds, to an encryptionschedule, an indication that the first portion of the user's personallyidentifiable information was encrypted using the first public encryptionkey and an indication that the second portion of the user's personallyidentifiable information was encrypted using the second publicencryption key and receives, from the data originator, a tokenindicating a request for redemption of the first and second portions ofthe user's personally identifiable information. The processor alsoselects, based on the encryption schedule, a first private encryptionkey of the token handler corresponding to the first public encryptionkey and decrypts, using the first private encryption key, the firstportion of the user's personally identifiable information encryptedusing the first public encryption key to produce the first portion ofthe user's personally identifiable information. The processor furtherselects, based on the encryption schedule, a second private encryptionkey of the token handler corresponding to the second public encryptionkey and decrypts, using the second private encryption key, the secondportion of the user's personally identifiable information encryptedusing the second public encryption key to produce the second portion ofthe user's personally identifiable information.

Certain embodiments provide one or more technical advantages. Forexample, an embodiment gives users more control over their PII byallowing users to give consent before access to the PII is granted. Asanother example, an embodiment improves the security of PII by storingthe PII on a user's personal device and/or by storing tokensrepresenting the PII on third-party servers. As yet another example, anembodiment improves the security of PII by maintaining sets of keys andby generating new sets of keys and deleting old sets of keysperiodically. Certain embodiments may include none, some, or all of theabove technical advantages. One or more other technical advantages maybe readily apparent to one skilled in the art from the figures,descriptions, and claims included herein.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present disclosure, referenceis now made to the following description, taken in conjunction with theaccompanying drawings, in which:

FIG. 1 illustrates an example system;

FIGS. 2A-2B illustrate an example device registration in the system ofFIG. 1;

FIGS. 3A-3G illustrate an example of storing and/or updating personallyidentifiable information using the system of FIG. 1;

FIGS. 4A-4B illustrate an example of redeeming personally identifiableinformation using the system of FIG. 1;

FIGS. 5A-5B illustrate an example device registration in the system ofFIG. 1; and

FIGS. 6A-6C illustrate an example key management scheme in the system ofFIG. 1.

DETAILED DESCRIPTION

Embodiments of the present disclosure and its advantages are bestunderstood by referring to FIGS. 1 through 6C of the drawings, likenumerals being used for like and corresponding parts of the variousdrawings.

Users provide information (e.g., name, address, telephone number, emailaddress, social security number, etc.) in a variety of contexts (e.g.,mortgage applications, credit card applications, financial accountapplications, air travel ticket orders, medical office visits, etc.). Ifthis information were exposed to or taken by a malicious user, then themalicious user would be able to use this information to impersonate theusers to conduct undesired or unwanted transactions.

In conventional systems, the users have very little control over theirinformation. The users provide their information to a provider to gainaccess to goods or services from the provider. The provider maintainsthe information (e.g., on a server). If that server were to be breachedby a malicious user, the information would be exposed to the malicioususer. Additionally, some providers even sell the information to otherproviders, often unbeknownst to the users. This sale and movement of theinformation further exposes the information to malicious users andlessens the control that the users have over such information.

This disclosure contemplates an unconventional system for securing anytype of information (e.g., a user's personally identifiable information(PII)). Generally, the system allows the user to store his PII on apersonal device, such as a smartphone. When a third party wants toaccess the user's PII (e.g., to update the PII or to retrieve the PII),a notification will be presented to the user on the personal deviceseeking consent to the access. The notification may inform the user asto what information is being requested and which entity is requestingthe access. The requested access will be denied unless the user consentsto the access. In this manner, the user is given control over thedissemination of his PII. Additionally, the system alters or adjusts thePII that is stored in third-party servers so that even if these serversare breached, the user's actual PII is not exposed. The security toolwill be described in more detail using FIGS. 1 through 6F. Although thefollowing embodiments describe a security tool protecting PII, thesecurity tool may be used to secure any type of information.

I. System Overview

FIG. 1 illustrates an example system 100 for protecting information(e.g., PII). As seen in FIG. 1 system 100 includes one or more devices104, a network 106, a data originator 108, a database 110, a cloudservice 112, and a token handler 114. Generally, system 100 protects PIIby storing a user's 102 PII in that user's 102 device 104. Access tothat PII is denied unless the user 102 consents to the access.

Devices 104 interact with other components of system 100. Generally,users 102 use devices 104 to receive and/or transmit messages to othercomponents of system 100. Devices 104 may store a user's 102 PII 116.User 102 may use devices 104 to grant or deny access to PII 116. In thismanner, user 102 controls who has access to PII 116 and when.

Devices 104 include any appropriate device for communicating withcomponents of system 100 over network 106. For example, devices 104 maybe a telephone, a mobile phone, a computer, a laptop, a tablet, anautomated assistant, and/or a cash register. This disclosurecontemplates device 104 being any appropriate device for sending andreceiving communications over network 106. As an example and not by wayof limitation, device 104 may be a computer, a laptop, a wireless orcellular telephone, an electronic notebook, a personal digitalassistant, a tablet, or any other device capable of receiving,processing, storing, and/or communicating information with othercomponents of system 100. Device 104 may also include a user interface,such as a display, a microphone, keypad, or other appropriate terminalequipment usable by user 102. In some embodiments, an applicationexecuted by device 104 may perform the functions described herein.

Network 106 allows communication between and amongst the variouscomponents of system 100. For example, user 102 may use devices 104 tocommunicate over network 106. This disclosure contemplates network 106being any suitable network operable to facilitate communication betweenthe components of system 100. Network 106 may include anyinterconnecting system capable of transmitting audio, video, signals,data, messages, or any combination of the preceding. Network 106 mayinclude all or a portion of a public switched telephone network (PSTN),a public or private data network, a local area network (LAN), ametropolitan area network (MAN), a wide area network (WAN), a local,regional, or global communication or computer network, such as theInternet, a wireline or wireless network, an enterprise intranet, or anyother suitable communication link, including combinations thereof,operable to facilitate communication between the components.

Data originator 108 is a third party who may want access to PII 116. Forexample, data originator 108 may be a credit card company, a medicaloffice, a bank, a brokerage, etc. Data originator 108 may use PII 116 toprovide and/or apply for goods and services for user 102. Generally,when data originator 108 wants to access PII 116, data originator 108first seeks approval from user 102 to access PII 116. If user 102 doesnot grant access to PII 116, then data originator 108 may not beprovided access to PII 116. In this manner, it may be more difficult fora malicious user to take PII 116 from data originator 108.

Database 110 stores information for data originator 108. Generally,database 110 stores tokens representing PII 116 and/or altered versionsof PII 116, also referred to as anonymized data. Data originator 108 canpresent the tokens and/or the anonymized data to indicate a request forPII 116. By storing tokens and/or anonymized data in database 110, thesecurity of PII 116 is improved because a malicious user can only taketokens and anonymized data, rather than PII 116, from data originator108 and/or database 110.

Cloud service 112 operates a storage system accessible through network106. Generally, cloud service 112 can be used to store anonymized dataand/or encrypted versions of PII 116. Various components of system 100such as devices 104, data originator 108, and/or token handler 114 mayaccess cloud service 112 to move information to and from othercomponents of system 100.

Token handler 114 facilitates access to PII 116. As seen in FIG. 1,token handler 114 includes a processor 118 and a memory 120. Thisdisclosure contemplates processor 118 and memory 120 being configured toperform any of the functions of token handler 114 described herein.

Processor 118 is any electronic circuitry, including, but not limited tomicroprocessors, application specific integrated circuits (ASIC),application specific instruction set processor (ASIP), and/or statemachines, that communicatively couples to memory 120 and controls theoperation of token handler 114. Processor 118 may be 8-bit, 16-bit,32-bit, 64-bit or of any other suitable architecture. Processor 118 mayinclude an arithmetic logic unit (ALU) for performing arithmetic andlogic operations, processor registers that supply operands to the ALUand store the results of ALU operations, and a control unit that fetchesinstructions from memory and executes them by directing the coordinatedoperations of the ALU, registers and other components. Processor 118 mayinclude other hardware that operates software to control and processinformation. Processor 118 executes software stored on memory to performany of the functions described herein. Processor 118 controls theoperation and administration of token handler 114 by processinginformation received from devices 104, network 106, and memory 120.Processor 118 may be a programmable logic device, a microcontroller, amicroprocessor, any suitable processing device, or any suitablecombination of the preceding. Processor 118 is not limited to a singleprocessing device and may encompass multiple processing devices.

Memory 120 may store, either permanently or temporarily, data,operational software, or other information for processor 118. Memory 120may include any one or a combination of volatile or non-volatile localor remote devices suitable for storing information. For example, memory120 may include random access memory (RAM), read only memory (ROM),magnetic storage devices, optical storage devices, or any other suitableinformation storage device or a combination of these devices. Thesoftware represents any suitable set of instructions, logic, or codeembodied in a computer-readable storage medium. For example, thesoftware may be embodied in memory 120, a disk, a CD, or a flash drive.In particular embodiments, the software may include an applicationexecutable by processor 118 to perform one or more of the functionsdescribed herein.

Generally, token handler 114 processes requests to store and/or accessPII 116. If user 102 consents to such storage and/or access, tokenhandler 114 facilitates the movement of PII 116 through system 100. Theinformation communicated in system 100 may be encrypted. The variouscomponents of system 100 (e.g., device 104, data originator 108, and/ortoken handler 114) may store or may be provided the public encryptionkeys of the other components such that each component of system 100 canencrypt messages intended for the other components of system 100. Incertain embodiments, a component of system 100 receives the publicencryption key of another component in response to a request for thepublic encryption key of that component. For example, data originator108 and/or device 104 may request and receive the public encryption keyof token handler 114. As another example, token handler 114 and device104 may request and receive the public encryption key of data originator108. The operation of system 100 will be described in more detail usingFIGS. 2A through 6C.

II. Initial Device Registration

FIGS. 2A and 2B show an example of initial device registration in system100 of FIG. 1. Generally, user 102 registers device 104 to gain accessto the various components of system 100. The registration processcreates an account for user 102 and allows token handler 114 torecognize user 102 and device 104 in the future.

FIG. 2A shows an example device 104 registration in system 100. As seenin FIG. 2A, device 104 includes a processor 202 and a memory 204. Thisdisclosure contemplates processor 202 and memory 204 being configured toperform any of the functions of device 104 described herein. Generally,device 104 registers with token handler 114 by providing particularinformation about user 102 to token handler 114.

Processor 202 is any electronic circuitry, including, but not limited tomicroprocessors, application specific integrated circuits (ASIC),application specific instruction set processor (ASIP), and/or statemachines, that communicatively couples to memory 204 and controls theoperation of device 104. Processor 202 may be 8-bit, 16-bit, 32-bit,64-bit or of any other suitable architecture. Processor 202 may includean arithmetic logic unit (ALU) for performing arithmetic and logicoperations, processor registers that supply operands to the ALU andstore the results of ALU operations, and a control unit that fetchesinstructions from memory and executes them by directing the coordinatedoperations of the ALU, registers and other components. Processor 202 mayinclude other hardware that operates software to control and processinformation. Processor 202 executes software stored on memory to performany of the functions described herein. Processor 202 controls theoperation and administration of device 104 by processing informationreceived from devices 104, network 106, and memory 204. Processor 202may be a programmable logic device, a microcontroller, a microprocessor,any suitable processing device, or any suitable combination of thepreceding. Processor 202 is not limited to a single processing deviceand may encompass multiple processing devices.

Memory 204 may store, either permanently or temporarily, data,operational software, or other information for processor 202. Memory 204may include any one or a combination of volatile or non-volatile localor remote devices suitable for storing information. For example, memory204 may include random access memory (RANI), read only memory (ROM),magnetic storage devices, optical storage devices, or any other suitableinformation storage device or a combination of these devices. Thesoftware represents any suitable set of instructions, logic, or codeembodied in a computer-readable storage medium. For example, thesoftware may be embodied in memory 204, a disk, a CD, or a flash drive.In particular embodiments, the software may include an applicationexecutable by processor 202 to perform one or more of the functionsdescribed herein.

User 102 installs application 206 to device 104. For example, user 102may download application 206 to device 104 and then install application206. After installing application 206, device 104 may executeapplication 206 to perform any of the functions of device 104 describedherein. For example, memory 204 may store application 206 and processor202 may retrieve application 206 from memory 204 and execute application206.

When user 102 launches application 206 for the first time, user 102 mayprovide information to application 206 to register. For example, user102 may provide a username and/or passphrase 208 that authenticates user102. User 102 may also provide other information during the registrationprocess such as, for example, a phone number 210 and an email address212. Device 104 uses this information to generate a salted passphrase214 specific to user 102. For example, device 104 may hash passphrase208 with phone number 210 and email address 212 to generate saltedpassphrase 214.

During the registration process device 104 may also generate a key pairfor user 102. The key pair includes the public key 216 and the privatekey 218 for device 104. Public key 216 may be shared with othercomponents of system 100 so that these components can encryptinformation intended for device 104. Device 104 uses private key 218 todecrypt information encrypted using public key 216. Device 104 continuesthe registration process by communicating salted passphrase 214 andpublic key 216 to token handler 114. When token handler 114 receives thesalted passphrase 214 and public key 216, token handler 114 mayunderstand that user 102 is attempting to register. Token handler 114uses salted passphrase 214 and public key 216 to generate additionalinformation that will be used in the future to protect the P II 116 ofuser 102.

Token handler 114 generates a key pair for token handler 114 usingpublic key 216. The key pair for token handler 114 includes public key220 and private key 222. Public key 220 may be used by components ofsystem 100 to encrypt messages intended for token handler 114. Tokenhandler 114 uses private key 222 to decrypt information encrypted usingpublic key 220. In some embodiments, public key 220 and private key 222may be generated independent of public key 216. Thus, token handler 114generates public key 220 and private key 222 without using public key216. In this disclosure, when a public keypair is referenced, anasymmetric key can be substituted, or a symmetric key protected by anasymmetric keypair (e.g., a public key encodes a symmetric key) can beused.

In some embodiments, device 104 may encrypt passphrase 208 and otherpersonal information (e.g., phone number 210 and email address 212)using public key 220 and send the encrypted information to token handler114. Token handler 114 then hashes the encrypted information to generatesalted passphrase 214. Token handler 114 then stores salted passphrase214 in a table (e.g., device registration table 228).

Token handler 114 may generate a user ID 226 for user 102. In someinstances, user 102 may have created user ID 226 and provided user ID226 to token handler 114. User ID 226 may be an identifier for user 102.

Token handler 114 creates a repository 224 that stores information foruser 102. For example, repository 224 may store tokens, anonymized data,and/or certain types of PII 116 for user 102. Token handler 114 maygenerate a repository name 232 for repository 224.

Token handler 114 adds certain information to a device registrationtable 228 to identify future requests from or to user 102. For example,token handler 114 may add public key 220, repository name 232, user ID226, and a hash of salted passphrase 214 to device registration table228. In certain embodiments, token handler 114 salts a providedpassphrase encrypted with a public key of the token hander 114 in anauthentication request. The token handler 114 constructs the saltedpassphrase and performs the hash, then looks for an entry matching thishash in its tables. If such an entry is found, the user isauthenticated. Any of this information may be used as an index intodevice registration table 228 to locate any of the other information.For example, if public key 220 is provided, token handler 114 mayretrieve user ID 226 and salted passphrase 214 from device registrationtable 228.

After token handler 114 has added the user's 102 information to deviceregistration table 228, token handler 114 communicates certaininformation back to device 104. In the illustrated example of FIG. 2A,token handler 114 communicates a consent object 230, repository name232, public key 220, and user ID 226. When device 104 receives thisinformation, device 104 may consider that registration was successful.Device 104 may store this information for future use.

After device 104 receives information from token handler 114 device 104may create a local repository 234. Device 104 may maintain repository234 to store PII 116 of user 102. In some embodiments, device 104 mayencrypt PII 116 using public key 220 and a key derived from saltedpassphrase 214 before storing PII 116 in repository 234. In this manner,even if a malicious user were to gain access to device 104, themalicious user will not be able to access PII 116 without getting tokenhandler 114 and user 102 to decrypt PII 114.

In certain embodiments, device 104 may push repository 234 to cloudservice 112. In this manner, a copy of repository 234 may be maintainedand accessed over network 106. As a result, even if repository 234 anddevice 104 were to become corrupted, a correct copy of repository 234may be retrieved from cloud service 112.

In some embodiments, user 102 may lock out an account if user 102believes that the account has been compromised. User 102 may use device104 or a web portal to request that the account of user 102 be lockedout. In response, token handler 114 may lock out the account of user 102so that future requests to access PII 116 of user 102 are rejected. Inthis manner, even if all of the security features provided by system 100are breached by a malicious user, user 102 may still lock out theaccount as a final fail safe.

FIG. 2B illustrates a method 240 of registering a device 104. Generally,device 104 and token handler 114 perform the steps of method 240. Byperforming method 240 device 104 may be registered to system 100.

In step 242, device 104 installs application 206. Device 104 thenprovides passphrase 208, phone number 210, and email address 212 in step244. Device 104 generates salted passphrase 214 in step 246. In someembodiments, device 104 generates salted passphrase 214 by combining andhashing passphrase 208, phone number 210, and email address 212. In step248, device 104 generates public key 216 and private key 218. Device 104then communicates salted passphrase 214 and public key 216 to tokenhandler 114.

When token handler 114 receives hashed salted passphrase 214 and publickey 216, token handler 114 may understand that device 104 is attemptingto register. In another embodiment, device 104 may pass saltedpassphrase 214 to token handler 114, allowing token handler 114 to hashsalted passphrase 214. In step 250, token handler 114 generates publickey 220 and private key 222. In some embodiments, token handler 114generates public key 220 and/or private key 222 based on public key 216.Token handler 114 generates user ID 226 in step 252. In someembodiments, token handler 114 may receive user ID 226 from user 102and/or device 104 rather than generating user ID 226. In step 254, tokenhandler 114 creates repository 224. Token handler 114 then adds user ID226, public key 220, repository name 232, and hashed, salted passphrase214 to device registration table 228. Token handler 114 communicatesconsent object 230, repository name 232, public key 220, and user ID 226to device 104.

When device 104 receives consent object 230, repository name 232, publickey 220, and user ID 226, device 104 may understand that registrationhas been successful. In step 260, device 104 creates local repository234. Device 104 may store consent object 230, public key 220, and userID 226 in local repository 234 in step 262. Device 104 may then requestPII 116 from user 102. As user 102 provides PII 116, device 104 maystore that PII 116 in repository 234. In some embodiments device 104 mayfirst encrypt PII 116 using public key 220 and a key derived from saltedpassphrase 214 before storing in repository 234.

Modifications, additions, or omissions may be made to method 240depicted in FIG. 2B. Method 240 may include more, fewer, or other steps.For example, steps may be performed in parallel or in any suitableorder. Any suitable component of system 100 may perform one or moresteps of the method 240.

III. Storing and Updating PII

FIGS. 3A-3G show examples of storing and updating PII using system 100.FIGS. 3A and 3B show user 102 using device 104 to store or update PII insystem 100. FIGS. 3C-3E show data originator 108 storing or updating PIIin system 100. FIGS. 3F and 3G show token handler 114 storing orupdating certain portions of PII. Generally, system 100 stores PII indevice 104 after user 102 gives consent, and system 100 provides a tokenand/or anonymized data to other components (e.g., data originator 108).In this manner, user 102 controls access to the PII using device 104,and a malicious user can take only tokens and/or anonymized data fromthe other components of system 100.

A. Storing and Updating PII with a User Device

FIG. 3A shows the storing and/or updating of PII 116 using device 104 insystem 100. Generally, user 102 can create or update PII 116 usingdevice 104. Device 104 can store PII 116 for future redemption. Tokenhandler 114 generates anonymized data for PII 116 that can be maintainedby third parties and used by third parties in the future to redeem PII116. In this manner, user 102 and device 104 control access to PII 116.

Device 104 receives PII 116 from user 102. User 102 may have created newPII 116 and inputted PII 116 into device 104. User 102 may have updatedexisting PII 116 by inputting PII 116 into device 104. Device 104 thenencrypts PII 116 using public key 220 of token handler 114 to createpayload 302. In some embodiments, device 104 may store PII 116 that hasbeen encrypted using public key 220 for future redemption. Device 104communicates payload 302 to token handler 114 to generate anonymizeddata and/or a token. Token handler 114 receives payload 302 from device104. Token handler 114 may decrypt payload 302 with private key 222 oftoken handler 114.

In some embodiments, after encrypting PII 116 using public key 220,device 104 encrypts PII 116 using a key derived from salted passphrase214 to create payload 302, which is PII 116 encrypted by public key 220and then salted passphrase 214. In other words, payload 302 is a doublyencrypted version of PII 116. In this manner, even if a malicious userwere to access a private encryption key of token handler 114 and tointercept payload 302, the malicious user would not be able to fullydecrypt payload 302 to access PII 116 without salted passphrase 214.Additionally, if the malicious user were to access device 104, themalicious user would not be able to decrypt payload 302 without saltedpassphrase 214. Device 104 then writes payload 302 to the repository234. The repository 234 changes would then be replicated in the cloud112. This would bypass the data authenticity mechanism, and the device104 would request an additional step to generate tokens 309 andanonymized data 304.

Token handler 114 generates one or more tokens 309 that represent storedinformation (e.g., PII 116, anonymized data 304, and/or ledger ID 308).A token 309 may indicate certain characteristics associated with thestored information. For example, token 309 may govern the entities thatare allowed to access the information. As another example, token 309 maygovern when access may be granted to and/or the manner in which accessis provided to the information. As yet another example, token 309 mayindicate where the information is stored (e.g., on device 104, on aserver, and/or in the cloud) and/or for how long token 309 is validand/or how many times the token can be redeemed, or how many times itcan be redeemed during a prescribed interval of time. As yet anotherexample, tokens 309 may specify how long redeemed data may reside intoken handler's 114 cache memory. Tokens 309 may be provided todifferent components of system 100 and/or different users so that thesecomponents and users can later redeem and/or access the information(e.g., PII 116) by presenting token 309. Token 309 further protects theinformation because even if a malicious user were to access token 309,the malicious user would not be able to determine or derive theinformation from token 309. Additionally, user 102 may prevent access tothe information by deleting or instructing the deletion of token 309from system 100. In this manner, if token 309 is subsequently presentedfor redemption, token handler 114 may prevent access to the information.

In particular embodiments, token 309 may indicate the loggingrequirements as token 309 and/or PII 116 is moved through system 100.For example, token 309 may indicate that logging should be performedeach time token 309 and/or PII 116 is stored and/or redeemed. Theresulting logs may be stored and/or redeemed in the same way that PII116 is stored and/or redeemed, as described herein. The logging willallow user 102 and system administrators to track which entities haveperformed which operations using token 309 and/or PII 116. The logs maynot reveal the actual PII 116, thus protecting the user's 102information. Additionally, by putting control of access to the log inthe user's 102 hands, a reduction in log data volume and storage needsmay result. Furthermore, by storing the log on device 104 where data isco-located, log searches may be performed by device 104 rather than byother components of system 100, thus reducing processing and I/0bandwidth relative to conventional server-side logging techniques.

In certain embodiments, token handler 114 generates anonymized data 304representing PII 116. Token handler 114 may generate anonymized data 304in any suitable manner. For example, token handler 114 may pre-generatea table of unique, suitable values and allocate and map values from thetable to PII 116 to produce anonymized data 304. Importantly, if amalicious user were to take anonymized data 304, the malicious userwould not be able to glean PII 116 from anonymized data 304. In someinstances, the malicious user may even believe that anonymized data 304is PII 116, because anonymized data 304 may have the same format as PII116. Importantly, anonymized data 304 is not a transformation of PII116. In other words, it is not possible to determine or derive PII 116from anonymized data 304 (e.g., by decrypting anonymized data 304 or byapplying a reverse function to anonymized data 304).

As an example, if PII 116 were a social security number of user 102,token handler 114 may generate anonymized data 304 by generating a tableof random social security numbers and allocating one of them in responseto a request to generate an anonymized social security number. In thismanner, anonymized data 304 still appears to be a social security numberbut is not a social security number of user 102. As another example, ifPII 116 is the name of user 102, anonymized data 304 may use a sequenceof random character values of PII 116. As a result anonymized data 304may be a random string of characters. In both examples, if a malicioususer were to access anonymized data 304, the malicious user would not beable to glean the user's social security number or name from anonymizeddata 304.

Token handler 114 stores anonymized data 304 in a ledger 306. Ledger 306is identified by a ledger ID 308. Token handler 114 may have generatedledger ID 308 if ledger 306 was also newly generated. In this manner,anonymized data 304 and ledger ID 308 uniquely identify PII 116. Asdiscussed further below, when token handler 114 is presented withanonymized data 304 and ledger ID 308, token handler will be able todetermine that PII 116 and/or token 309 is being requested. Tokenhandler 114 communicates anonymized data 304 and ledger ID 308 to othercomponents of system 100, such as for example, device 104 and dataoriginator 108 so that these components can later redeem PII 116 bypresenting anonymized data 304 and ledger ID 308.

Device 104 receives token 309 and/or anonymized data 304 and ledger ID308 from token handler 114. Device 104 stores token 309 and/oranonymized data 304 and ledger ID 308 in repository 234. In someembodiments, device 104 may further push repository 234 to cloud service112 for storage on a cloud. As a result of this operation, device 104stores a local copy of token 309 and/or anonymized data 304 and ledgerID 308. Additionally, device 104 stores a local copy of PII 116encrypted using public key 220.

In some embodiments, device 104 may not store or maintain a local copyof PII 116, token 309, anonymized data 304, and/or ledger ID 308.Rather, device 104 stores this information on a server or in a cloud. Inother words, device 104 may store payload 302, token 309, anonymizeddata 304, and/or ledger ID 308 in repository 234. Device 104 may thenpush repository 234 to the cloud or to a remote server for storage.Device 104 may then delete or erase local copies of PII 116, token 309,payload 302, anonymized data 304, and/or ledge ID 308. In this manner,this information may not be compromised if device 104 is taken by amalicious user.

As discussed previously, system 100 is not limited to the storage and/orupdating of personally identifiable information. Rather, any type ofinformation may be handled by system 100 to protect that information.For example, confidential information of a business or enterprise (e.g.,database credentials) may be protected using system 100. Token 309and/or anonymized data 304 and ledger ID 308 that correspond to theconfidential information may be generated and stored in a similar mannerthat PII 116 is secured by system 100 (e.g., as described in FIGS.3A-3G).

In some embodiments, token handler 114 further encrypts PII 116 withcertain information (e.g., an identifier for user 102, an identifier fortoken handler 114, and/or an identifier for data originator 108) andstores the encrypted PII 116 for subsequent validation of PII 116 duringredemption. For example, token handler 114 may store the encrypted PII116 in a Merkle tree. During redemption, if requested PII 116 isprovided using device 104 in response to a redemption request, tokenhandler 114 can first verify the provided PII 116 by comparing itagainst the encrypted PII 116 stored in the Merkle tree. Token handler114 may decrypt the encrypted PII 116 and then compare the two versionsof PII 116 to see if the provided PII 116 has been altered. In thismanner, even if user 102 decides to maliciously alter the provided PII116, token handler 114 can detect and prevent that altered PII 116 frombeing provided.

FIG. 3B shows an example method 310 for storing and/or updating PII 116using device 104. By performing method 310, device 104 is given controlover access to PII 116. Device 104 receives PII 116 in step 312. User102 may have inputted PII 116 into device 104. The user 102 may becreating PII 116 and/or updating PII 116 in device 104. In step 314,device 104 encrypts PII 116 with public key 220 to create a payload 302.In some embodiments, device 104 further encrypts PII 116 with a keybased on salted passphrase 214 to form payload 302. In this manner,payload 302 is a doubly encrypted version of PII 116. Device 104 thencommunicates payload 302 to token handler 114.

Token handler 114 decrypts payload 302 with private key 222 of tokenhandler 114 to produce PII 116. Token handler 114 generates token 309that represents PII 116 in step 317. In step 318, token handler 114generates anonymized data 304 for PII data 116. Token handler 114 maygenerate anonymized data 304 by generating random character sequences(for names) or nine digit numbers (for social security numbers), forexample. In this manner, anonymized data 304 may resemble the format ofPII 116, but not have the actual values of PII 116. As a result, amalicious user who gains access to anonymized data 304 will not be ableto glean PII 116 from anonymized data 304. In some embodiments, tokenhandler 114 scrambles PII 116 or generates a random string of charactersand/or symbols to generate anonymized data 304.

In step 320, token handler 114 stores anonymized data 304 in a ledger306. Ledger 306 may be identified by ledger ID 308. In the event thattoken handler 114 generated ledger 306 to store anonymized data 304,token handler 114 may also generate ledger ID 308 that identifies ledger306. Token handler 114 then communicates token 309 and/or anonymizeddata 304 and ledger ID 308 to other components of system 100, such asdevice 104.

Device 104 may store token 309 and/or anonymized data 304 correspondingledger ID 308. As a result, device 104 may store a local copy of token309, anonymized data 304, ledger ID 308, and PII 116 encrypted usingpublic key 220.

Modifications, additions, or omissions may be made to method 310depicted in FIG. 3B. Method 310 may include more, fewer, or other steps.For example, steps may be performed in parallel or in any suitableorder. Any suitable component of system 100 may perform one or moresteps of the method 310.

B. Storing and Updating PII with a Data Originator

FIG. 3C shows the creation and/or updating of PII 116 by a third party,such as data originator 108. Data originator 108 may be any entityseparate from user 102 and token handler 114. For example, dataoriginator 108 may be an entity that provides a good or service to user102 after user 102 has provided PII 116. Data originator 108 may be amedical office, financial institution, etc. Data originator 108 mayinclude a number of agents that interact with user 102 and/or device104. As seen in FIG. 3C, data originator 108 may include a processor 326and a memory 328. Processor 326 and memory 328 may be configured toperform any of the functions of data originator 108 and/or its agentsdescribed herein.

Processor 326 is any electronic circuitry, including, but not limited tomicroprocessors, application specific integrated circuits (ASIC),application specific instruction set processor (ASIP), and/or statemachines, that communicatively couples to memory 328 and controls theoperation of data originator 108. Processor 326 may be 8-bit, 16-bit,32-bit, 64-bit or of any other suitable architecture. Processor 326 mayinclude an arithmetic logic unit (ALU) for performing arithmetic andlogic operations, processor registers that supply operands to the ALUand store the results of ALU operations, and a control unit that fetchesinstructions from memory and executes them by directing the coordinatedoperations of the ALU, registers and other components. Processor 326 mayinclude other hardware that operates software to control and processinformation. Processor 326 executes software stored on memory to performany of the functions described herein. Processor 326 controls theoperation and administration of data originator 108 by processinginformation received from devices 104, network 106, and memory 328.Processor 326 may be a programmable logic device, a microcontroller, amicroprocessor, any suitable processing device, or any suitablecombination of the preceding. Processor 326 is not limited to a singleprocessing device and may encompass multiple processing devices.

Memory 328 may store, either permanently or temporarily, data,operational software, or other information for processor 326. Memory 328may include any one or a combination of volatile or non-volatile localor remote devices suitable for storing information. For example, memory328 may include random access memory (RAM), read only memory (ROM),magnetic storage devices, optical storage devices, or any other suitableinformation storage device or a combination of these devices. Thesoftware represents any suitable set of instructions, logic, or codeembodied in a computer-readable storage medium. For example, thesoftware may be embodied in memory 328, a disk, a CD, or a flash drive.In particular embodiments, the software may include an applicationexecutable by processor 326 to perform one or more of the functionsdescribed herein.

Data originator 108 receives PII 116 from user 102 and/or device 104.User 102 may have provided PII 116 to data originator 108 so that dataoriginator 108 can provide a good or service to user 102. For example,if data originator 108 is a medical office, user 102 may have provided aname and/or address to the medical office to receive medical treatment.If data originator is a financial institution, user 102 may haveprovided PII 116 such as a name, address, and social security number toopen an account with the financial institution.

After receiving PII 116, data originator 108 does not store PII 116permanently. Rather, data originator 108 prepares PII 116 for handlingby token handler 114. Data originator 108 encrypts PII 116 using publickey 220 of token handler 114 to create payload 330. Data originator 108then communicates payload 330 to token handler 114. In this manner, dataoriginator 108 does not store PII 116, which improves the security ofPII 116. For example, a malicious user will not be able to access PII116 through data originator 108.

Token handler 114 receives payload 330 from data originator 108. Payload330 may also include an identifier of data originator 108 (DO ID 332).Payload 330 may also include a consent ID 334. Payload 330 may alsoinclude information about user 102. Token handler 114 uses thatinformation to index into device registration table 228 to determine theuser 102 corresponding to PII 116. For example, token handler 114 mayretrieve a user ID 226 from device registration table 228 using thatinformation. Token handler 114 may also decrypt payload 330 usingprivate key 222 of token handler 114 to access PII 116 (e.g., togenerate token 309 and/or anonymized data 304).

Token handler 114 implements a polling system by which other componentsof system 100 may be notified of pending tasks. In other words, whentoken handler 114 needs device 104 and/or data originator 108 to performa particular task, token handler 114 does not initiate contact with dataoriginator 108 or device 104. Rather, token handler 114 waits for device104 or data originator 108 to establish a connection with token handler114 before token handler 114 informs device 104 or data originator 108of any pending tasks. It is the responsibility of device 104 and dataoriginator 108 to periodically establish a connection with token handler114 to check if there are any pending tasks. In this manner, even if amalicious user were to acquire contact information for device 104 and/ordata originator 108, the malicious user would not be able to spoof orimpersonate token handler 114 and initiate contact with device 104 ordata originator 108 and hijack device 104 and data originator 108. As aresult, the security of device 104 and data originator 108 is improved.

Generally, token handler 114 uses one or more queues (e.g., instructionqueue 340 and status queue 342) to manage the polling process. Whendevice 104 and data originator 108 establish a connection with tokenhandler 114, device 104 and data originator 108 check particular queuesto determine any pending tasks and performs any of the pending tasksthat token handler 114 wants device 104 and data originator 108 toperform. As seen in FIG. 3C, token handler 114 maintains an instructionqueue 340 and a status queue 342. Token handler 114 uses these queues tolet device 104 and/or data originator 108 know of pending tasks.

Token handler 114 generates a payload 336 using information from payload330 and device registration table 228. Payload 336 indicates a requestto store PII 116. Token handler 114 may also generate a request ID 338that identifies the request to store PII 116. Token handler 114 may alsouse consent ID 334 to look up a token creation template and include itin the payload 336. The token creation template may include adescription of what data will be written, a description of who mayretrieve PII 116, and a description of the purposes for which PII 116may be used. Token handler 114 inserts payload 336 into instructionqueue 340 to inform other components of system 100 that the storage ofPII 116 is requested. Token handler 114 may also update a status of therequest in status queue 342 to requested or pending. Token handler 114communicates request ID 338 to other components of system 100 such asdata originator 108 so that those components can check on the status ofthe pending storage task. In this manner, components of system 100, suchas data originator 108, may reference request ID 338 through aconnection with token handler 114 to check the status of the pendingstorage task. For example, if data originator 108 sees that the statusof a request corresponding to request ID 338 in status queue 342 ispending, then data originator 108 may determine that the request isstill pending and wait.

After inserting payload 336 into instruction queue 340, token handler114 waits for device 104 to establish a connection with token handler114. As discussed above, device 104 establishes a connection with tokenhandler 114 periodically according to the polling scheme. When device104 establishes a connection with token handler 114, device 104 may seethat payload 336 is waiting for device 104 in instruction queue 340.Token handler 114 may update the status of the request in status queue342 to pending or in contact.

In response to seeing payload 336 in instruction queue 340, device 104retrieves payload 336 from instruction queue 340. Device 104 generates anotification 346 that seeks consent from user 102 to allow the storagetask from data originator 108. Notification 346 may include or begenerated from anonymized data 304 included in payload 336. Notification346 may include or be generated from consent language included inpayload 336. Device 104 may generate notification 346 using theinformation in payload 336 such as, for example, the data originator ID332, the user ID 226, and the consent ID 334. Device 104 may thenpresent notification 346 to user 102 such as, for example, through adisplay. User 102 can give consent or deny consent. If user 102 deniesconsent, then device 104 and/or token handler 114 may reject the pendingstorage task. Token handler 114 may then update the status of therequest in status queue 342 to rejected.

If user 102 gives consent for the pending storage task, then device 104encrypts portions of payload 336 using salted passphrase 214 (or a keybased on salted passphrase 214) to produce payload 348. In other words,payload 348 includes a doubly encrypted version of PII 116 that has beenfirst encrypted using public key 220 and then encrypted using saltedpassphrase 214. Device 104 then stores payload 348 in repository 234.Before committing portions of payload 348 to repository 234, device 104may include an encryption schedule describing what steps must beundertaken to decrypt portions of payload 348. Device 104 may furtherpush repository 234 to cloud service 112.

Additionally, if user 102 gives consent, device 104 communicates arequest 349 to token handler 114 indicating a request to generate token309 and/or anonymized data 304. Request 349 may include a token creationtemplate extracted from payload 348. Token handler 114 receives request349 from device 104 and generates token 309 and/or anonymized data 304in response. Token handler 114 then stores anonymized data 304 in ledger306. As discussed previously, token handler 114 may generate or useledger ID 308 to identify ledger 306. Token handler 114 may then storetoken 309 and/or anonymized data 304 and ledger ID 308 in a database ormemory 120 (e.g., a cache of memory 120) for subsequent retrieval. Tokenhandler 114 then updates the status of the storage request in statusqueue 342 to ready. In some embodiments, token handler 114 may storetoken 309 and/or anonymized data 304 and ledger ID 308 in status queue342. As discussed previously, token 309 may indicate the accessprivileges and the manner and time in which the stored information is tobe accessed.

Data originator 108 may poll token handler 114 to check the status ofthe pending storage task. When data originator 108 sees that the statusis ready, data originator 108 may determine that the storage task isready or complete. Data originator 108 may then retrieve token 309and/or anonymized data 304 and ledger ID 308 from token handler 114(e.g., from memory 120 or status queue 342). Data originator 108 maythen store token 309 and/or anonymized data 304 and ledger ID 308 intodatabase 110 for future use. For example, data originator 108 maypresent token 309 and/or anonymized data 304 and ledger ID 308 to tokenhandler 114, to retrieve PII 116 in the future. In this manner, device104 controls the storage of PII 116 in system 100.

In certain instances, token handler 114 may also initiate communicationwith other components of system 100 (e.g., device 104 and dataoriginator 108) rather than waiting for these components to initiatecommunication with token handler 114 through the polling system. Forexample, token handler 114 may initiate communication when a request isurgent or in emergency situations. As another example, token handler 114may initiate communication when token handler 114 knows that thecomponent is ready and expecting a communication from token handler 114(e.g., when the component has already initiated data storage orredemption).

FIGS. 3D and 3E shows a method 350 for storing PII 116 using dataoriginator 108. Generally, when data originator 108 wants to store PII116, device 104 should first give consent to the storage. If consent isgiven, anonymized data 304 and/or token 309 is generated using PII 116and provided to data originator 108.

In step 352, data originator 108 receives PII 116. A user 102 may haveused device 104 to provide PII 116. As another example, a user 102 mayhave provided PII 116 directly to data originator 108. Data originator108 encrypts PII 116 with public key 220 of token handler 114 in step354. Data originator 108 then creates payload 330 using the encryptedPII 116 in step 356. Payload 330 may also include identifyinginformation for data originator 108 and user 102. Payload may alsoinclude a consent ID 230. Data originator 108 communicates payload 330to token handler 114.

Token handler 114 receives payload 330 and retrieves a user ID 226 froma device registration table 228 using the information in payload 330 instep 358. Token handler 114 then validates the data originator in step360. Validation may involve (1) authenticating the device of dataoriginator 108 (2-way TLS) and retrieving registration data for dataoriginator 108, (2) retrieving a consent object 230 and determining ifdata originator 108 has permission to use consent object 230, and (3)confirming that data originator 108 has sufficient privileges andauthorization to store PII 116 of user 102 for subsequent retrieval oruse as specified by consent object 230. User 102 may have previouslyprovided such authorization. User 102 may also approve storage of some,all, or none of PII 116. Token handler 114 then creates payload 336 instep 362. Payload 336 may indicate the pending storage task. Tokenhandler 114 inserts payload 336 into instruction queue 340 in step 364.Token handler 114 then waits for device 104 to establish a connectionwith token handler 114.

In step 366, device 104 establishes a connection with token handler 314.Device 104 may see that payload 336 is in instruction queue 340indicating a pending request to store PII 116. Device 104 then retrievespayload 336 from token handler 114. In step 368, device 104 presentsnotification 346 seeking consent to store PII 116. Token handler 114 mayupdate the status of the storage task in status queue 342 to pending instep 370. In step 372, device 104 receives consent from user 102 tostore PII 116. Device 104 encrypts payload 336 using salted passphrase214 to produce payload 348 in step 374. Device 104 then communicatesrequest 349 to token handler 114. Device 104 may also write payload 348to repository 234 in step 376. In certain embodiments, device 104generates an unsigned token and adds the unsigned token to request 349.In some embodiments, user 102 may select which portions of PII 116 willbe referenced by token 309.

Token handler 114 generates and/or signs token 309 representing portionsof PII 116 in step 379. In step 380, token handler 114 generatesanonymized data 304 representing PII 116. In some embodiments, tokenhandler 114 generates a random string of characters and/or symbols toform anonymized data 304. In step 382, token handler 114 storesanonymized data 304 in ledger 306. Ledger 306 may be identified usingledger ID 308. In step 384, token handler 114 updates status queue 342to indicate that the data is ready.

Token handler 114 then waits for data originator 108 to establish aconnection with token handler 114. When data originator 108 establishesa connection with token handler 114, data originator 108 may see thatthe status of the storage task is ready. In response, data originator108 retrieves token 309 and/or anonymized data 304 and ledger ID 308from token handler 114. In step 386, data originator 108 stores token309 and/or anonymized data 304 and ledger ID 308 to database 110 forfuture use.

In some embodiments, token handler 114 may push data to data originator108 using, for example, a webhook called by the token handler 114 whentoken 309 and/or anonymized data 304 and ledger ID 308 are ready.

When device 104 establishes a connection with token handler 114, device104 may retrieve token 309 and/or anonymized data 304 and ledger ID 308from token handler 114. In step 388, device 104 stores pseudo-anonymizeddata 304 and ledger ID 388 for future use.

In this manner, user 102 and device 104 are given control over when PII116 may be stored or updated. As a result, a malicious user will not beable to create fake PII 116 for user 102 because user 102 would notprovide consent in response to notification 346 generated for storingthe fake PII 116.

Modifications, additions, or omissions may be made to method 350depicted in FIGS. 3D and 3E. Method 350 may include more, fewer, orother steps. For example, steps may be performed in parallel or in anysuitable order. Any suitable component of system 100 may perform one ormore steps of the method 350.

C. Storing, Updating, and Redeeming Permanent Data

FIG. 3F shows token handler 114 handling permanent data. Permanent datais a type of PII that is governed by particular laws and/or regulations.Typically, these laws or regulations may require that access be given tocertain types of PII for certain purposes. To comply with these laws orregulations, token handler 114 would grant access to these types of PIIwithout receiving consent from a user 102. Generally, token handler 114identifies these types of PII and stores encrypted versions of this PIIin a cloud so that token handler 114 can access this PII without firstbeing granted permission by a user 102. In certain embodiments, tokenhandler 114 may still seek consent from user 102 before accessing thisPII, but in the event that the user 102 does not give consent, tokenhandler 114 may still access the PII to comply with the laws orregulations.

Token handler 114 receives payload 330. As discussed above, payload 330may include PII 116 that has been encrypted using public key 220 oftoken handler 114. Data originator 108 may have provided payload 330 totoken handler 114. Token handler 114 decrypts payload 330 using privatekey 222 of token handler 114 to produce PII 116.

PII 116 may include certain types of PII 116 that are governed by lawsor regulations. For example, these laws or regulations may require thataccess be given to PII 116 even without user consent. Token handler 114may identify portions 390 of PII 116 that are governed by these laws orregulations. Token handler 114 may encrypt these portions 390 using apublic key 392 of data originator 108 and then a public key 220 of tokenhandler 114 to form a payload 394. As a result, portion 390 is doublyencrypted using keys of data originator 108 and token handler 114. Tokenhandler 114 then stores payload 394 in a cloud for future retrieval anduse. Because portion 390 has been encrypted using the keys of tokenhandler 114 and data originator 108, token handler 114 and dataoriginator 108 may decrypt portion 390 without intervention from device104.

When data originator 108 requests the portion 390 of PII 116 (e.g., bycommunicating a request for portion 390 to token handler 114), tokenhandler 114 may retrieve payload 394 from the cloud and decrypt payload394 using private key 222 of token handler 114 to produce portion 390encrypted using public key 392 of data originator 108. Token handler maythen communicate portion 390 encrypted using public key 392 of dataoriginator 108 to data originator 108. Data originator 108 may thendecrypt, using a private key of data originator 108, portion 390encrypted using public key 392 to produce portion 390. In this manner,data originator 108 can retrieve portion 390 even without user consent.

In some embodiments, token handler 114 still gives user 102 anopportunity to consent to the retrieval of portion 390. If user 102consents, then the regular redemption of PII 116 can occur, as describedbelow. If user 102 does not consent, then token handler 114 may provideportion 390 to data originator 108 using the process discussed above.

FIG. 3G shows an example method 396 for storing permanent data. Incertain embodiments, token handler 114 performs method 396. Byperforming method 396, token handler 114 stores PII 116 that is governedby laws or regulations requiring access without consent.

In step 396A, token handler 114 receives payload 330. Token handler 114decrypts payload 330 with private key 222 to produce PII 116 in step396B. In step 396C, token handler 114 identifies a portion 390 of PII116 that is governed by laws or regulations. These laws or regulationsmay require that access be given to portions 390 without user consent.

In step 396D, token handler 114 encrypts portion 390 with public key 392of data originator 108, and then public key 220 of token handler 114 toproduce a payload 394. Token handler 114 then stores payload 394 in thecloud in step 396E.

Token handler 114 may also store payload 394 on the user's 102 device104. In this manner, the data repository in the cloud 112 can remainconsistent with the data repository 234 on the user's 102 device 104.

Modifications, additions, or omissions may be made to method 396depicted in FIG. 3G. Method 396 may include more, fewer, or other steps.For example, steps may be performed in parallel or in any suitableorder. Any suitable component of system 100 may perform one or moresteps of the method 396.

IV. Redeeming PII

FIGS. 4A and 4B show an example of redeeming PII 116 in system 100.Generally, data originator 108 presents a token 309 and/or anonymizeddata 304 to indicate a request to obtain or use the PII 116. After user102 consents to the request, token handler 114 performs a series ofsteps so that data originator 108 can receive the PII 116 or allow athird party to provide a service with the PII 116. In this manner, user102 controls access to the PII 116.

FIG. 4A shows redemption of PII 116 in system 100. The process beginswhen token handler 114 receives token 309 and/or anonymized data 304 andledger ID 308, indicating a request to redeem PII 116. As discussedpreviously, token 309 and anonymized data 304 and ledger ID 308 mayuniquely identify PII 116. In addition, token 309 identifies dataoriginator 108 and user 102. Data originator 108 may have retrievedtoken 309 and/or anonymized data 304 and ledger ID 308 from database110. Data originator 108 communicates token 309 and/or anonymized data304 and ledger ID 308 to token handler 114 to indicate a request toredeem PII 116. In some embodiments, the process begins with device 104communicating token 309 and/or anonymized data 304 and ledger ID 308 todata originator 108 and/or directly to token handler 114. For example,data originator 108 may have asked user 102 to provide PII 116, and inresponse, user 102 uses device 104 to communicate token 309 and/oranonymized data 304 and ledger 308 to data originator 108 and/or tokenhandler 114.

Token handler 114 receives token 309 and/or anonymized data 304 andledger ID 308. Token handler 114 generates a payload 402 using token 309and/or anonymized data 304 and ledger ID 308. Payload 402 indicates arequest to redeem PII 116 corresponding to token 309 and/or anonymizeddata 304 and ledger ID 308. Token handler 114 inserts payload 402 intoinstruction queue 340. Token handler 114 may then wait for device 104 topoll token handler 114.

In certain embodiments, token handler 114 validates token 309 todetermine whether data originator 108 is allowed to access PII 116before further requesting consent from device 104. Token 309 is signedwith a signature created with a private key 222 of token handler 114,and in this way, may guarantee that token 309 has not been altered bydata originator 108 or a malicious user. Also, token 309 may designatedata originator 108 as the legitimate user of token 309. Further, token309 designates how PII 116 can be accessed or used. For example, token309 may stipulate that PII 116 must be presented to another serverrather than being made available to data originator 108.

While anonymized data 304 may map to token 309, token 309 may referenceadditional PII data elements for which data originator 108 did notsupply a corresponding anonymized data item. Token handler 114 mayexclude a missing data item from payload 402 to indicate to device 104that the missing data item is not to be redeemed. In this manner, tokenhandler 114 prevents device 104 from being presented with illegitimateredemption requests in the event that a malicious user accesses token309 and/or anonymized data 304 and/or ledger ID 308, and furtherrestricts data originator 108 from gaining access to data outside thepurview of data originator 108, in the event that tokens are shared bymultiple data originators. By designating data originator 108 as thelegitimate user of token 309, token handler 114 prevents another userfrom intercepting or accessing and redeeming a token issued for use bydata originator 108.

In some embodiments, data originator 108 presents token 309 and notanonymized data 304 and ledger ID 308 to request access to PII 116.Token handler 114 identifies from token 309 the PII 116 that is beingrequested. Token handler 114 may further refer to token 309 to determinewhether certain security checks have passed (e.g., whether token 309indicates that data originator 108 may request PII 116 at this time orin a particular manner or for a particular purpose by including, forexample, a redirect URL for another service to receive PII 116). Tokenhandler 114 performs the series of steps described below to redeem orprovide PII 116 to data originator 108.

In some embodiments, data originator 108 presents anonymized data 304and ledger ID 308 instead of token 309. Token handler 114 identifiesfrom anonymized data 304 and ledger ID 308 a token 309 that correspondsto anonymized data 304 and ledger ID 308. Token handler 114 thenidentifies from token 309 that PII 116 is being requested. Token handler114 may further refer to token 309 to determine whether certain securitychecks have passed (e.g., whether token 309 indicates that dataoriginator 108 may request PII 116 at this time or in a particularmanner). Token handler 114 performs the series of steps described belowto redeem or provide PII 116 to data originator 108 or provide PII 116to another service.

As discussed previously, device 104 periodically polls token handler 114to see if there are any pending tasks waiting for device 104. Whendevice 104 establishes a connection with token handler 114, device 104may see payload 402 in instruction queue 340 and in response, determinethat token handler 114 has received token 309 and/or anonymized data 304and ledger ID 308, indicating a request to redeem PII 116. Token handler114 may update a status for the request to redeem PII 116 in statusqueue 342 to pending. When device 104 sees payload 402 in pending queue340, device 104 generates and presents notification 404 to user 102.Notification 404 requests consent from user 102 to redeem PII 116. User102 may consent to revealing to or allowing data originator 108 to useall, some, or none of the PII 116 described in notification 404. If user102 does not consent to reveal to or allow use of any portions of PII116 to data originator 108, then the request to redeem PII 116 is deniedand the status for the request to redeem PII 116 in status queue 342 isupdated to denied.

If the user 102 consents, then device 104 retrieves payload 302. Asdescribed previously, payload 302 represents PII 116 encrypted usingpublic key 220 of token handler 114 and then an encryption key derivedfrom salted passphrase 214 of user 102. Device 104 may have retrievedpayload 302 from the cloud, a server, or from a local repository 234. Ifpayload 302 is stored on the cloud or a server, then device 104effectively acts as a consent mechanism for gaining access to some orall of PII 116.

In some embodiments, consent to store and/or redeem PII 116 (or toperform any other task) may be required from and given by entities otherthan user 102. For example, token 309 may indicate other users 102 orother entities that need to provide consent before certain tasks (e.g.,logging, redeeming, storing) can be performed. If these tasks arerequested, token handler 114 may seek consent from these other users 102or entities. Consent may be provided on devices of those other users 102or entities. Consent may also be provided if those other users 102 orentities provide to token handler 114 tokens 309 that were generated forthose users 102 and/or entities. When the required consent has beengiven, token handler 114 may commence the task.

Device 104 retrieves encrypted data from payload 302 according to thewishes of the user. Device 104 decrypts payload 302 using saltedpassphrase 214. Device 104 then encrypts the resulting payload 302 usingpublic key 392 of data originator 108 to create payload 406. In otherwords, payload 406 represents PII 116 encrypted using public key 220 oftoken handler 114 and then public key 392 of data originator 108. Device104 communicates payload 406 to token handler 114. In certainembodiments, token handler 114 may have retrieved public key 392 basedon token 309 and/or anonymized data 304 and ledger ID 308. Token handlerthen communicates public key 392 to device 104. In some embodiments,device 104 decrypts payload 302 using salted passphrase 214 to producePII 116 encrypted using public key 220 of token handler 114. Tokenhandler 114 then applies encryption using public key 392 of dataoriginator 108 to produce payload 406.

In some embodiments, token 309 may specify that data originator 108receive certain items of anonymized data from payload 302 in place ofcorresponding data items from PII 116. Thus, payload 409 may includereal data from PII 116 intermixed with portions of anonymized data 304.

Token handler 114 receives payload 406 from device 104. Token handler114 stores payload 406 in memory 120 (e.g., in a cache of memory 120)and updates the status of the request for PII 116 in status queue 342 toready. Token handler 114 may then wait for data originator 108 to polltoken handler 114. In some embodiments, token handler 114 may storepayload 406 in status queue 342. When data originator 108 establishes aconnection with token handler 114, data originator 108 may see thestatus of the request in status queue 342 is ready indicating that therequest to redeem has been approved and is ready. Data originator 108may retrieve payload 406 from memory 120 or status queue 342 of tokenhandler 114. Data originator 108 then decrypts payload 406 using privatekey 408 of data originator 108 to generate payload 410. Payload 410 mayrepresent PII 116 encrypted using public key 220 of token handler 114.Data originator 108 then communicates payload 410 to token handler 114.

In some embodiments, when token handler 114 receives payload 406 fromdevice 104, token handler 114 calls an internal or external serviceindicated in token 309 and stores the result of this service call inmemory 120. When data originator 108 establishes a connection with tokenhandler 114, data originator 108 may see the status of the request instatus queue 342 indicating that the request to the internal or externalservices has completed and results or response, if any, are ready.

If the token 309 specifies that PII 116 should be made available to dataoriginator 108, token handler 114 decrypts payload 410 using private key222 of token handler 114 to produce PII 116. Token handler 114 thenprovides PII 116 to data originator 108. In certain embodiments, tokenhandler 114 may provide PII 116 to data originator 108 by encrypting PII116 using public key 392 of data originator 108 and then communicatingthe encrypted PII 116 to data originator 108. In this manner, dataoriginator 108 is provided PII 116 after user 102 consents to theredemption of PII 116.

In certain embodiments, when token handler 114 receives payload 410 fromdevice 104, it decrypts payload 410 with a private key 222 of the tokenhandler 114 and encrypts payload 410 with a public key 392 of dataoriginator 108 and places it into a cache and notifies data originator108 that payload 410 is ready. In certain embodiments, token handler 114encrypts payload 410 a second time with public key 220 of token handler114 before placing PII 116 twice encrypted into the cache. Dataoriginator 108 then requests PII 116 from the cache, and in responsetoken handler 114 decrypts PII 116, now encrypted with only a public key392 of the data originator 108, and presents it to data originator 108.

In certain embodiments, token 309 is redeemed to accomplish tasks otherthan redeeming PII 116. For example, token 309 may be redeemed foranother token 309 that is associated with different privileges andrights. Data originator 108 and/or device 104 may communicate token 309to token handler 114 along with a request 412. Request 412 may indicatethe type of task that is being requested (e.g., redeem PII 116, storePII 116, generate new token 309, etc.). If request 412 indicates that anew token 309 is to be generated, token handler 114 may determine thefeatures of the new token 309 based on other information within request412. For example, request 412 may indicate the changes between token 309and new token 309. In response, token handler 114 may insert request 412and/or token 309 into instruction queue 340. When device 104 noticesthat request 412 and/or token 309 is in instruction queue 340, device104 may request consent from user 102 for the generation of new token309. When consent is given, token handler 114 may generate new token 309that includes the changes to token 309 and update the status of request412 in status queue 342. Device 104 and/or data originator 108 mayretrieve new token 309 from token handler 114 in response to the updatedstatus of request 412 in status queue 342. The ability to requestgeneration of new token 309 may allow access rights and/or privileges tobe altered without altering or accessing PII 116 or any other sensitiveinformation of user 102. For example, user 102 may change informationsuch as access rights, membership subscription, and/or loggingrequirements without having other components of system 100 accessing PII116 or other sensitive information of user 102.

FIG. 4B shows a method 420 for redeeming PII 116 in system 100.Generally, PII 116 is redeemed after user 102 consents to the redemptionof PII 116.

Token handler 114 receives token 309 and/or anonymized data 304 andledger ID 308 in step 422. Token handler 114 may have received token 309and/or anonymized data 304 and ledger ID 308 from data originator 108.In some embodiments, token handler 114 received token 309 and/oranonymized data 304 and ledger ID 308 from device 104. For example, dataoriginator 108 may have asked user 102 to provide PII 116. In response,device 104 communicates token 309 and/or anonymized data 304 and ledgerID 308 to token handler 114.

Token handler 114 generates payload 402 in step 424. Payload 402 may begenerated using token 309 and/or anonymized data 304 and ledger ID 308.Token handler 114 inserts payload 402 into instruction queue 340 in step426. Token handler 114 then waits for device 104 to poll token handler114.

In step 428, device 104 establishes a connection with token handler 114.Token handler 114 then updates status queue 342 to pending in step 430.Device 104 may establish a connection with token handler 114 anddetermine that payload 402 is in instruction queue 340 indicating arequest for PII 116. Device 104 generates notification 404 in step 432to seek consent from user 102 to the redemption of PII 116. Device 104receives consent in step 434. In response, device 104 decrypts payload302 with salted passphrase 214 and then encrypts with public key 392 ofdata originator 108 to produce payload 406 in step 436. Device 104communicates payload 406 to token handler 114. In some embodiments,device 104 decrypts payload 302 with salted passphrase 214 and thencommunicates the result to token hander 114. Token handler 114 thenencrypts using public key 392 of data originator 108 to produce payload406.

Token handler 114 updates status queue 342 to ready and stores payload406 in step 438. Token handler 114 then waits for data originator 108 topoll token handler 114. After data originator 108 establishes aconnection with token handler 114, data originator 108 determines thatthe status of the request in status queue 342 is ready and retrievespayload 406 from token handler 114. Data originator 108 then decryptspayload 406 with private key 408 of data originator 108 to producepayload 410 in step 440. Data originator 108 then communicates payload410 to token handler 114. Token handler 114 then decrypts payload 410using private key 222 of token handler 114 to produce PII 116 in step442. Token handler 114 then provides PII 116 to data originator 108. Forexample, token handler 114 may encrypt PII 116 using public key 392 ofdata originator 108 and communicate the result to data originator 108.As another example, token handler 114 may request that data originator108 call a dispatch who can provide PII 116 over the telephone. As yetanother example, token handler 114 may communicate the result (e.g., anencrypted telephone number of user 102) to another service, such as atelephone carrier, to allow data originator 108 to contact user 102.

Modifications, additions, or omissions may be made to method 420depicted in FIG. 4B. Method 420 may include more, fewer, or other steps.For example, steps may be performed in parallel or in any suitableorder. Any suitable component of system 100 may perform one or moresteps of the method 420.

V. Subsequent Device Registration

FIGS. 5A and 5B show an example of subsequent device registration.Generally, user 102 can register additional devices 104 into system 100.Each registered device 104 is given a copy of the repository 234.

FIG. 5A shows an example of subsequent device registration in system100. As seen in FIG. 5A, user 102 maintains two devices 104A and 104B.Device 104A has been previously registered with system 100. User 102 isattempting to register the second device 104B in the example of FIG. 5A.

User 102 downloads application 206 to device 104B. User 102 may theninstall application 206 to device 104B. When device 104B executesapplication 206, user 102 may provide account credentials to application206. For example, user 102 may provide passphrase 208 and/or user ID226. Device 104B then generates a public key 502 and a private key 504for device 104B. Device 104B communicates public key 502 to tokenhandler 114.

Token handler 114 receives public key 502 from device 104B. Tokenhandler 114 then generates public key 506 and private key 508 for tokenhandler 114 based on public key 502. Token handler 114 then addsinformation about device 104B to device registration table 228. In thismanner, device registration table 228 may associate device 104B withuser 102. Device registration table 228 thus shows that user 102 isassociated with two devices: 104A and 104B.

Token handler 114 then initiates the process for duplicating repository234 onto device 104B. In some embodiments, cloud service 112 maintains acopy of repository 234. In these embodiments, device 104B downloads acopy of repository 234 from cloud service 112. In some embodiments cloudservice 112 does not maintain a copy of repository 234. In theseembodiments, token handler 114 and/or device 104A uploads a temporarycopy of repository 234 to cloud service 112. Device 104B then downloadsa copy of repository 234 from cloud service 112. After the download iscomplete, device 104B and/or token handler 114 deletes the copy of therepository 234 from cloud service 112. In this manner device 104B, isregistered to system 100 and user 102 may use device 104A or device 104Bto interact with other components of system 100.

FIG. 5B shows an example method 510 for registering subsequent devices104 in system 100. In step 512, device 104 installs application 206.Device 104 then receives passphrase 208 in step 514. In step 516, device104 generates public and private keys 502 and 504. Device 104 thencommunicates public key 502 to token handler 114. Token handler 114generates public and private keys 506 and 508 in step 518. Token handler114 then retrieves information for user 102 from a device registrationtable 228 in step 520. Token handler 114 determines whether a cloudimage of repository 234 exists in step 522. If the cloud image does notexist, token handler 114 asks device 104 to upload a temporary cloudrepository in step 524. In step 526, device 104 downloads repository 234from the cloud. In step 528, token handler 114 deletes the temporaryrepository 234 in the cloud if it was determined in step 522 that nocloud image of the repository 234 existed. In some embodiments, device104 deletes the temporary repository 234 in the cloud after downloadingtemporary repository 234.

Modifications, additions, or omissions may be made to method 510depicted in FIG. 5B. Method 510 may include more, fewer, or other steps.For example, steps may be performed in parallel or in any suitableorder. Any suitable component of system 100 may perform one or moresteps of the method 510.

VI. Key Management

FIGS. 6A-6C show an example key management scheme in system 100.Generally, token handler 114 uses a set of keys to encrypt PII such thatdifferent keys are used to encrypt different portion of the PII. In thismanner, even if a malicious user takes a key, the malicious user wouldnot be able to decrypt all of the PII. Additionally, token handler 114generates new set of keys periodically and also deletes old sets of keysperiodically. As a result, even if a malicious user takes a key, theusefulness of that key is time limited.

FIG. 6A shows an example of the key management scheme. As seen in FIG.6A, token handler 114 generates and maintains multiple sets of keys 602.In the example of FIG. 6A, token handler 114 has generated andmaintained a first set of keys 602A, a second set of keys 602B, and athird set of keys 602C. Token handler 114 may have generated each set ofkeys 602 at different times. For example, token handler 114 may generatea new set of keys 602 every month. In the first month, token handler 114generated set 602A. In the second month, token handler 114 generated set602B. In the third month, token handler 114 generated set 602C. Tokenhandler 114 communicates these sets 602 of keys to other components ofsystem 100, such as device 104 and data originator 108.

These components use keys 606 from the set 602 to encrypt PII 116. Thesecomponents then send the encrypted PII 116 to token handler 114. Incertain embodiments, these components use different keys 606 to encryptdifferent portions of PII 116. In the example of FIG. 6A, the componentsencrypt first portion 604 of PII 116 using public key 606A. Thecomponents encrypt second portion 608 of PII 116 using a second publickey 606B. Public keys 606A and 606B belong to the same set 602. Forexample, public key 606A and 606B may belong to set 602A. Portions 604and 608 may be different attributes of PII 116. For example, firstportion 604 may be an email address and second portion 608 may be asocial security number. By encrypting different portions 604 and 608 ofPII 116 using different keys 606, the impact of a key 606 being taken bya malicious user is reduced. For example, if public key 606A or itscorresponding private key were taken by a malicious user, the malicioususer would not be able to access second portion 608 of PII 116 usingthose keys. In certain embodiments, the components of system 100, suchas data originator 108 and device 104, randomly select keys 606 from themost current set 602 of keys to encrypt information. In this manner, itmay be more difficult for a malicious user to determine which key 606was used to encrypt a piece of information.

Token handler 114 adds to an encryption schedule 610 information aboutwhich keys 606 were used to encrypt the various portions 604 and 608 ofPII 116. In the example of FIG. 6A, encryption schedule 610 shows thatfirst portion 604 was encrypted using public key 606A and second portion608 was encrypted using public key 606B. Token handler 114 may refer toencryption schedule 610 when PII 116 is requested to determine the keys606 that were used to encrypt the various portions 604 and 608 of PII116. Token handler 114 may then select the correct corresponding key todecrypt first portion 604 and second portion 608. Token handler 114 maycommunicate encryption schedule 610 to other components of system 100,such as device 104 and data originator 108, so that these components canrefer to the encryption schedule 610 to determine which keys were usedto encrypt certain information. For example, token handler 114 maycommunicate encryption schedule 610 to device 104 and/or data originator108 when device 104 and/or data originator 108 establish a connectionwith token handler 114. In some embodiments, token handler 114communicates one or more applicable keys 606 to a requesting componentof system 100 rather than communicating encryption schedule 610 to thesecomponents. In other words, token handler 114 determines which keys 606are applicable in response to a request and communicates those keys 606to the requesting component. In this manner, the requesting component isnot tasked with maintaining the encryption schedule 610 and withdetermining the applicable keys.

Token handler receives token 309 and/or anonymized data 304 and ledgerID 308, which indicates a request to redeem PII 116. As a result tokenhandler 114 refers to encryption schedule 610 to determine how todecrypt the various portions of PII 116. In the example of FIG. 6A,token handler 114 determines that first portion 604 of PII 116 wasencrypted using public key 606A. As a result, token handler 114 usesprivate keys 612A that corresponds to public key 606A to decrypt firstportion 604 of PII 116. Token handler 114 determines from the encryptionschedule 610 that second portion 608 of PII 116 was encrypted usingpublic key 606B. In response, token handler 114 uses private key 612Bwhich corresponds to public key 606B to decrypt second portion 608 ofPII 116.

Token handler 114 may maintain a key vault 611 that stores the variouskeys 606 and 612 used to encrypt and/or decrypt information.Alternatively, token handler 114 may use an external or third-party keymanagement system, referencing and caching keys stored in that system.Each key in key vault 611 is identified by an ordinal. The key vault 611also maintains the key value for each ordinal. By referring to key vault611 and specific ordinals, token handler 114 may retrieve the keys thatare used to encrypt and decrypt PII 116. In some embodiments, theordinals identify references to keys. The references may be used toidentify keys stored in key vault 611. If a malicious user were to gainaccess to the ordinals, the malicious user would need to map theordinals to their appropriate references and then use the references toaccess the keys in key vault 611. Thus, an additional layer of securityis added by using ordinals and references. In certain embodiments, tokenhandler 114 determines whether the age of a set 602 of keys exceeds athreshold based on the ordinals of the keys in that set 602. Forexample, if each set 602 includes ten keys, then ordinals 1 through 10belong to a first set 602 and ordinals 11 through 20 belong to a secondset 602. The second set 602 would have been generated a time periodafter the first set 602. When the ordinals indicate that the set 602 isolder than another threshold, that set 602 can be deleted. In someembodiments, token handler 114 also identifies keys based on theirordinals. For example, encryption schedule 610 may identify which keywas used to encrypt certain information using the ordinals of thosekeys.

In certain embodiments, token handler 114 generates a new set 602 ofkeys periodically. For example, token handler 114 may generate set 602Ain the first month, set 602B in the second month, and set 602C in thethird month. When token handler 114 generates a new set 602 of keys,token handler 114 may use keys from that set 602 to encrypt informationmoving forward until another set 602 of keys is generated. Token handlermay use set 602A to encrypt information until the age of set 602Aexceeds a threshold (e.g., one month). When the age of set 602A exceedsone month, token handler 114 may generate set 602B and begin using set602B to encrypt information. When the age of set 602B exceeds one month,token handler 114 may generate set 602C and begin using set 602C toencrypt information.

In some embodiments, token handler 114 re-encrypts previously encryptedinformation (e.g., first portion 604 and second portion 608) when a newset of keys is generated. For example, if public keys 606A and 606B werein first set 602A, then when token handler 114 generates set 602B, tokenhandler 114 may use public keys in set 602B to re-encrypt first portion604 and second portion 608. In this manner, the encryption of the firstportion 604 and the second portion 608 are kept up-to-date. In certainembodiments, token handler 114 may first verify that first portion 604and second portion 608 are unchanged or untampered before re-encryptingusing the newly generated set of keys. In this manner, the generation ofa new set of keys does not present an opportunity for a malicious actorto change the PII 116.

For example, when device 104 connects to token handler 114 to requestinstructions (e.g., from instruction queue 340), token handler 114 mayprovide device 104 with an ordinal. Device 104 may then compare thatordinal with stored ordinals to determine if any of the stored ordinalsare expired or outdated. For example, if the provided ordinal is greaterthan a stored ordinal, then the stored ordinal may be expired oroutdated. Device 104 may then initiate an operation that is equivalentto a data redemption and then a data push for data that corresponds to akey for the expired or outdated ordinal. This operation may be handledat a lower priority by token handler 114, which may result in the databeing re-encrypted with keys from the latest key windows. There-encrypted data may then be stored on device 104 with ordinals for thelatest encryption keys. This operation may include the steps: (1) device104 uses the active passphrase 208 to partially decrypt the data; (2)device 104 passes the partially decrypted data as a payload to thespecial key rotation queue; the payload includes the old encryptionschedule and the new one; (3) token handler 114 removes the payload fromqueue; (4) token handler 114 decrypts the data with the correspondingold token handler 114 private key(s); (5) if the data is permanent data,then the data is supplied to data originator 108 for decryption andre-encryption with a new key; (6) token handler 114 encrypts the datawith a new key from the current window; (7) token handler 114 removesthe old encryption schedule from the payload and places the resultingpayload into instruction queue 340 for device 104; (8) when connectedand executing instructions, device 104 re-encrypts and stores the dataand new encryption schedule. In one embodiment, data is processed onedata push payload or redemption schedule at a time. In some embodiments,many push payloads are processed at once.

In one embodiment, system 100 takes a lazy approach to re-encrypting thedata. Device 104 does not proactively determine which data should beencrypted and initiate data re-encryption. Instead, when a dataredemption request comes in, device 104 compares the ordinals in theencryption schedule with the ordinal provided by token handler 114. Ifthe provided ordinal is greater than a corresponding ordinal in theencryption schedule, then a data push request is placed into instructionqueue 340, causing the data to be re-encrypted. If the ordinals in thecurrent encryption schedule correspond to keys that have been deleted,then system 100 returns an error. In some embodiments, the data ondevice 104 encrypted with out-of-date keys is destroyed, making itimpossible for an attacker to decrypt data using captured keys, thusfurther enhancing the security of system 100.

In certain embodiments, data re-encryption also occurs when user 102changes passphrases 208. The user's 102 passphrases 208 are alsorepresented by ordinals. In one embodiment, the user's 102 oldpassphrase 208 is encrypted with the new passphrase 208 and stored intothe user's 102 repository. Device 104 submits requests for all obsoletedata to be re-encrypted with the new passphrase 208. A markerinstruction is added to instruction queue 340. When device 104 reachesthis instruction, it marks the old passphrase 208 “obsolete”;thereafter, redemption requests for data encrypted with the oldpassphrase 208 are rejected. In one embodiment, such invalid requestsare detected by, and rejected at, device 104; in another embodiment,device 104 communicates the ordinal of the current passphrase 208 totoken handler 114, and token handler 114 rejects invalid dataredemptions before they reach device 104. In one embodiment, when alldata has been re-encrypted with the new passphrase 208, the obsoletepassphrase 208 encrypted with the new passphrase 208 is deleted and/orall data encrypted with the old passphrase 208 is deleted, making itimpossible to find data encrypted with a captured passphrase 208 andfurther enhancing the security of system 100.

In some embodiments, token handler 114 deletes sets 602 of keys when theage of the set 602 exceeds a predetermined threshold. For example, tokenhandler 114 may delete a set 602 of keys after six months. In thismanner if a malicious user were to take keys or a set 602 of keys, theusefulness of those keys would be time limited. For example, if tokenhandler 114 receives a request to redeem PII 116 that was encryptedusing a key that has been deleted due to age, token handler 114 may knowto reject that request. Using the previous example, token handler 114may keep set 602A until the age of set 602A exceeds a threshold (e.g.,six months). When the age of set 602A exceeds six months, token handler114 may delete set 602A. Similarly, when the age of sets 602B and/or602C exceeds six months, token handler 114 may delete sets 602B and/or602C.

If the security of data originator 108 or token handler 114 iscompromised, after the attacker is barred from further access to system100, token handler 114 or data originator 108 can generate a new key orkey flight, and the provided ordinal can be set to this new value or tothe origin of the key flight. In this way, even if an attacker gainsaccess to data originator 108 or token handler 114 and captures privateencryption keys, data cannot be redeemed using the captured encryptionkeys, thus enhancing the security of system 100.

FIG. 6B shows an example method 620 of managing keys in system 100. Instep 622, token handler 114 generates a set 602 of keys. Token handler114 then communicates that set 602 of keys to data originator 108. Dataoriginator 108 may use keys from that set 602 of keys to encrypt PII 116in step 624. For example, data originator 108 may encrypt a firstportion 604 of PII 116 using a first public key 606A and a secondportion 608 of PII 116 using a second public key 606B to create apayload. Data originator 108 may communicate the payload to tokenhandler 114.

Token handler 114 receives the payload from data originator 108 and addsencryption information to an encryption schedule 610 in step 626. Theencryption schedule 610 may indicate that first portion 604 wasencrypted using public key 606A and that second portion 608 wasencrypted using public key 606B.

Data originator 108 then communicates token 309 and/or anonymized data304 and ledger ID 306 to token handler 114 indicating a request toredeem PII 116. Token handler 114 selects first and second private keys612A and 612B in step 628. Token handler 114 may have selected first andsecond private keys 612A and 612B based on the information in theencryption schedule 610. Token handler 114 decrypts first portion 604 ofPII 116 using first private key 612A in step 630. Token handler 114decrypts second portion 608 of PII 116 using second private key 612B instep 632.

Modifications, additions, or omissions may be made to method 620depicted in FIG. 6B. Method 620 may include more, fewer, or other steps.For example, steps may be performed in parallel or in any suitableorder. Any suitable component of system 100 may perform one or moresteps of the method 620.

FIG. 6C shows an example method 640 of managing keys in system 100. Incertain embodiments, token handler 114 performs method 640. In step 642,token handler 114 determines that an age of a set 602 of keys exceeds afirst predetermined time threshold. In step 644, token handler 114generates a new set of keys 602. For example, the first predeterminedtime threshold may have been one month. In response to determining thatthe set 602 of keys was generated over a month ago, token handler 114regenerates the new set 602 of keys.

In step 646, token handler 114 encrypts data using the new set 602 ofkeys. Token handler 114 then determines that an age of the set 602 ofkeys exceeds a second predetermined time threshold in step 648. A secondpredetermined time threshold may be a longer period, such as, forexample, six months. In step 650, token handler 114 deletes the set 602of keys. In this manner, it is no longer possible for token handler 114to encrypt or decrypt information using the set 602 of keys. In step652, token handler 114 receives token 309 and/or anonymized data 304 anda ledger ID 308 indicating a request for data encrypted using the set602 of keys.

Token handler 114 rejects the request in step 654 because the set 602 ofkeys has been deleted. In this manner, token handler 114 improves thesecurity of PII 116 because even if a malicious user were to take a set602 of keys, the usefulness of that set 602 of key was time limited.

Modifications, additions, or omissions may be made to method 640depicted in FIG. 6C. Method 640 may include more, fewer, or other steps.For example, steps may be performed in parallel or in any suitableorder. Any suitable component of system 100 may perform one or moresteps of the method 640.

Generally, system 100 provides several advantages over conventionalsecurity systems, as discussed above. For example, when PII 116 is to bestored or updated, system 100 first seeks consent from user 102 for thePII 116 store or update. If the user 102 grants consent, then the system100 stores the PII 116 in the user's 102 personal device 104 or updatesthe PII 116 stored in the user's personal device 104, then generates adata access token 309 and anonymized data 304 mapped to the data accesstoken 309. If the anonymized data 304 were to be captured by a malicioususer, it would not be possible for the malicious user to determine theuser's 102 actual PII 116 from the anonymized data 304. Similarly, ifthe malicious user were to capture a data access token 309, it would notbe possible for the malicious user to determine the user's 102 actualPII 116 from the token 309. If the system 100 or the user 102 learn thata malicious user has captured a data access token 309, and/or wish toblock access to PII 116 by means of the anonymized data 304, the token309 can be removed from the token handler 114, guaranteeing that the PII116 can no longer be accessed using the specific anonymized data 304,while allowing other anonymized data 304 mapped to other data accesstokens 309 continued access to the PII 116.

If an undetected malicious user penetrates the token handler 114 andcaptures a private key 222 of the token handler 114, the malicious userwill not be able to decrypt the data without also learning the user's102 passphrase and the data used to salt the passphrase and to encryptthe information. Alternatively, a malicious user who has gained accessto the token handler 114 may try simulating a request to redeem theuser's 102 data and obtaining the user's 102 explicit consent. If therequest doesn't match similar requests, the user 102 has reason towithhold this consent, allowing the user 102 a means to thwart amalicious user from accessing their data. Similarly, if the malicioususer gains control of the user's 102 device 104 and attempts to decryptthe information from the device 104, the malicious user will failwithout the user's 102 salted passphrase 214 and the token handler 114private key 222. If the malicious user attempts to trigger a redemptionflow from the device 104, the malicious user runs the risk of detectionby either the user 102 or the token handler 114, resulting in lockdownof the account. Additionally, use restrictions placed on tokens 309,such as a token 309 can only be used one time, or limited number oftimes, or may be used a limited number of times in a specific intervalof time, allow the token handler 114 to mark a user's 102 account withan “at-risk” status, causing the token handler 114 to automaticallyreject requests to redeem data. In these ways, the security of the PII116 is improved over conventional systems.

Although the present disclosure includes several embodiments, a myriadof changes, variations, alterations, transformations, and modificationsmay be suggested to one skilled in the art, and it is intended that thepresent disclosure encompass such changes, variations, alterations,transformations, and modifications as fall within the scope of theappended claims.

What is claimed is:
 1. A system for protecting personally identifiableinformation, the system comprising: a device of a user configured to:receive personally identifiable information the user; and encrypt thepersonally identifiable information to produce first encryptedpersonally identifiable information; a token handler separate from thedevice, the token handler configured to: receive the first encryptedpersonally identifiable information from the device of the user; decryptthe first encrypted personally identifiable information to produce thepersonally identifiable information; generate a token representing thepersonally identifiable information; and receive the token indicating arequest for the personally identifiable information; wherein the deviceof the user is further configured to: after the token handler hasreceived the token indicating the request for the personallyidentifiable information, receive consent from the user to provide thepersonally identifiable information; in response to receiving theconsent from the user, encrypt the personally identifiable informationto produce second encrypted personally identifiable information; andcommunicate the second encrypted personally identifiable information tothe token handler.
 2. The system of claim 1, wherein: the device of theuser is further configured to: receive a passphrase from the user; hashthe passphrase with a phone number and an email address of the user toproduce a salted passphrase; and generate a public encryption key of thedevice; and the token handler is further configured to generate, basedon the public encryption key of the device, a public encryption key ofthe token handler, wherein encrypting the personally identifiableinformation to produce the first encrypted personally identifiableinformation comprises encrypting the personally identifiable informationusing the public encryption key of the token handler.
 3. The system ofclaim 2, wherein the token handler is further configured to delete thepublic encryption key of the token handler in response to adetermination that the public encryption key of the token handler hasbeen active for a period of time that exceeds a threshold.
 4. The systemof claim 2, further comprising a second device of the user, the tokenhandler further configured to: receive, from the second device, a publicencryption key of the second device and the salted passphrase; generatea second public encryption key of the token handler based on the publicencryption key of the second device; link the second device to thedevice of the user using the salted passphrase, the second device isconfigured to download the personally identifiable information from acloud after being linked to the device of the user.
 5. The system ofclaim 4, wherein the second device is further configured to delete thepersonally identifiable information from the cloud after downloading thepersonally identifiable information from the cloud.
 6. The system ofclaim 1, wherein: the token handler is further configured to, inresponse to receiving the token, wait for the device to establish aconnection with the token handler; and the device is further configuredto: establish the connection with the token handler; determine that thetoken handler has received the token; and in response to determiningthat the token handler has received the token, present a notificationmessage seeking the consent from the user to provide the personallyidentifiable information from the device, the user responds to thenotification message to provide the consent to communicate thepersonally identifiable information from the device.
 7. The system ofclaim 1, wherein: the token handler is further configured to communicatethe token to the device; and the device is further configured to: createa local repository; store the token to the device in the localrepository; and push the local repository to a cloud.
 8. The system ofclaim 7, wherein the token handler is further configured to: encrypt aportion of the personally identifiable information using a publicencryption key of a data originator and the public encryption key of thetoken handler; store, in the cloud, the portion of the personallyidentifiable information encrypted using the public encryption key of adata originator and the public encryption key of the token handler;receive a request for the portion of the personally identifiableinformation; in response to the request for the portion of thepersonally identifiable information, retrieve, from the cloud, theportion of the personally identifiable information encrypted using thepublic encryption key of the data originator and the public encryptionkey of the token handler; and decrypt the encrypted portion of thepersonally identifiable information using a private encryption key ofthe token handler to produce the portion of the personally identifiableinformation encrypted using the public encryption key of the dataoriginator.
 9. The system of claim 1, wherein the token handler isfurther configured to: adjust the personally identifiable information toproduce anonymized data; and generate an identifier for a ledger storingthe anonymized data.
 10. The system of claim 1, wherein the tokenhandler is further configured to: receive a request to lock out theuser; receive the token indicating a second request for the personallyidentifiable information after receiving the request to lock out theuser; and in response to the request to lock out the user, reject thesecond request for the personally identifiable information.
 11. A methodfor protecting personally identifiable information, the methodcomprising: receiving, by a device of a user, personally identifiableinformation the user; encrypting, by the device, the personallyidentifiable information to produce first encrypted personallyidentifiable information; receiving, by a token handler separate fromthe device, the first encrypted personally identifiable information fromthe device of the user; decrypting, by the token handler, the firstencrypted personally identifiable information to produce the personallyidentifiable information; generating a token representing the personallyidentifiable information; receiving, by the token handler, the tokenindicating a request for the personally identifiable information; afterthe token handler has received the token indicating the request for thepersonally identifiable information, receiving, by the device, consentfrom the user to provide the personally identifiable information fromthe device in response to the request for the personally identifiableinformation; in response to receiving the consent from the user,encrypting, by the device, the personally identifiable information toproduce second encrypted personally identifiable information; andcommunicating, by the device, the second encrypted personallyidentifiable information to the token handler.
 12. The method of claim11, further comprising: receiving, by the device, a passphrase from theuser; hashing, by the device the passphrase with a phone number and anemail address of the user to produce a salted passphrase; generating, bythe device, a public encryption key of the device; generating, by thetoken handler, based on the public encryption key of the device, apublic encryption key of the token handler, wherein encrypting thepersonally identifiable information to produce the first encryptedpersonally identifiable information comprises encrypting the personallyidentifiable information using the public encryption key of the tokenhandler.
 13. The method of claim 12, further comprising deleting, by thetoken handler, the public encryption key of the token handler inresponse to a determination that the public encryption key of the tokenhandler has been active for a period of time that exceeds a threshold.14. The method of claim 12, further comprising: receiving, by the tokenhandler, from a second device of the user, a public encryption key ofthe second device and the salted passphrase; generating, by the tokenhandler, a second public encryption key of the token handler based onthe public encryption key of the second device; linking, by the tokenhandler, the second device to the device of the user using the saltedpassphrase; and downloading, by the second device, the personallyidentifiable information from a cloud after being linked to the deviceof the user.
 15. The method of claim 14, further comprising deleting, bythe second device, the personally identifiable information from thecloud after downloading the personally identifiable information from thecloud.
 16. The method of claim 11, further comprising: waiting, by thetoken handler, in response to receiving the token, for the device toestablish a connection with the token handler; establishing, by thedevice, the connection with the token handler; determining, by thedevice, that the token handler has received the token; and in responseto determining that the token handler has received the token,presenting, by the device, a notification message seeking the consentfrom the user to provide the personally identifiable information fromthe device, the user responds to the notification message to provide theconsent to communicate the personally identifiable information from thedevice.
 17. The method of claim 11, further comprising: communicating,by the token handler, the token to the device; creating, by the device,a local repository; storing, by the device, the token to the device inthe local repository; and pushing, by the device, the local repositoryto a cloud.
 18. The method of claim 17, further comprising: encrypting,by the token handler, a portion of the personally identifiableinformation using a public encryption key of a data originator and thepublic encryption key of the token handler; storing, by the tokenhandler, in the cloud, the portion of the personally identifiableinformation encrypted using the public encryption key of a dataoriginator and the public encryption key of the token handler;receiving, by the token handler, a request for the portion of thepersonally identifiable information; in response to the request for theportion of the personally identifiable information, retrieving, by thetoken handler, from the cloud, the portion of the personallyidentifiable information encrypted using the public encryption key ofthe data originator and the public encryption key of the token handler;and decrypting, by the token handler, the encrypted portion of thepersonally identifiable information using a private encryption key ofthe token handler to produce the portion of the personally identifiableinformation encrypted using the public encryption key of the dataoriginator.
 19. The method of claim 11, further comprising adjusting, bythe token handler, the personally identifiable information to produceanonymized data; and generating, by the token handler, an identifier fora ledger storing the anonymized data.
 20. The method of claim 11,further comprising: receiving, by the token handler, a request to lockout the user; receiving, by the token handler, the token indicating asecond request for the personally identifiable information afterreceiving the request to lock out the user; and in response to therequest to lock out the user, rejecting, by the token handler, thesecond request for the personally identifiable information.